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METHOD AND SYSTEM FOR through an IDE interface/bus. When the Firmware stored in 

PROGRAMMING A PERIPHERAL FLASH Flash ROM needs to be updated. In the traditional method, 

MEMORY VIA AN IDE BUS the Flash ROM should be firstly disconnected from the 

peripheral, then is put into the programming equipment to be 

^ a ^ T ^„^ T ,™ ^„ ™_ 5 re-programmed. After the new Firmware has been success- 

BACKGROUND OF THE INVENTION fijfy ^ Rash R0M , it can be plugged into the 
1. Field of the Invention peripheral again. Due to these complicate process, the 
This invention relates to a computer control system, and traditional method is very inconvenient. Moreover, after 
more particularly to a method used in a system for program- Products have been shipped to end-users, the traditional 
ming a peripheral flash read-only memory (ROM) via an 10 mem od is un-reasonable since most users have no program- 
integrated device electronics (IDE) interface. min S equipment. 

I Ascription of Related Art SUMMARY OF THE INVENTION 

Recently, computer industry has been rapidly developed. 
Its various periphery hardware devices are also accordingly 15 * l at * east objective of the present invention to 

developed. As the computer system is continuously provide a method for a computer system to program a flash 

developing, in order to satisfy some new developed sped- ROM, which is usually used to store a firmware code, 

fixations or protocols or improve the compatibility with through redefining an ATA task files with respect to an IDE 

other devices, various related firmware codes are necessary interface. The flash ROM can be direcdy programmed by a 

to be updated. Tnis results in that a lot of firmware data/code ^ nos * computer without going through the programming 

to control the periphery devices are necessary to be fre- equipment. 

quendy read or updated. The firmware code generally is It is at least another objective of the present invention to 

stored in a flash ROM. The computer system needs a method provide a flash controller, which can directly communicate 

to be able to rapidly and conveniently program the flash with a host computer through an IDE interface and directly 

ROM so as to update the firmware code/data. ^ program the flash ROM. The flash controller is independent 

Currently, several methods are used by a computer system t0 device hardware type, 

to read the firmware code stored in the flash ROM. In a In accordance with the foregoing and other objectives of 

system disclosed by U.S. Pat. No. 5,603,056, a control the present invention, a method for programming a periph- 

program for controlling a hard disk drive (HDD) and a ery flash ROM is provided. The method includes disabling 

rewrite program for rewriting the control program are stored 30 other access to a flash ROM as a host computer requests to 

together in an electrically erasable programmable ROM program or update a firmware code in the flash ROM. 

(EEPROM). Upon entering the rewrite mode, a central Several ATA task files in the host computer are redefined, in 

processing unit (CPU) in the HDD saves the control pro- which the ATA task files usually are defined in ATA speci- 

gram in the flash EEPROM into a random access memory fication and are used as register-level communication inter- 

(RAM). The CPU erases the flash EEPROM and restores the 35 face between the host computer and an IDE periphery 

rewrite program of the RAM in to the flash EEPROM. The . device. The firmware code from the host is transported 

CPU receives a new control program from a host computer through an IDE interface and then is written into the flash 

and loads it in the flash EEPROM. The erasing of the flash ROM through a programming control means, such as a flash 

EEPROM and the loading of the new control program are controller. The flash controller interprets all IDE interface 

performed by the CPU in accordance with the rewrite 40 activities and issues a read/write flash ROM cycle. The flash 

program saved in the RAM. In this conventional manner, a controller provides a software method, a hardware method, 

small computer system interface (SCSI) connector or an AT or even a mixed method of software and hardware, to 

attachment (ATA) connector are used to serve as an input/ program the flash ROM. For the software method the 

output (I/O) interface and perform a serial communication firmware code is direcdy written into the flash ROM through 

with the host computer by using unassigned pins of the 45 the flash controller. For the hardware method, the method 

connectors. Since the . used interface is not a general uses a buffer, such as a RAM, to store the firmware code if 

interface, this method cannot generally applied in various more than one flash ROM cycles are needed in one request, 

types of computer mother boards. Other methods are also Then, the firmware code stored in the buffer is sequentially 

disclosed by U.S. Pat. Nos. 5,408,624 and 5,729,683 but written into the flash ROM through the flash controller, 

they are complicate and also depends on different system 50 In accordance with the foregoing and other objectives of 

tv P e * the present invention, a system for programming a periphery 

Another conventional system using the IDE interface to flash ROM is provided. The system includes a host 

update firmware code stored in a flash ROM is also pro- computer, an IDE interface, a flash controller, a flash ROM, 

posed. Since the IDE interface is generally used in various and a microprocessor. The flash controller is coupled to the 

periphery devices, the method can have loose restriction. A 55 host computer through the IDE interface. The flash ROM 

compact-disk (CD) read-only-memory (ROM), or called and the microprocessor are also coupled tq the flash con- 

CDROM, is an essential periphery device of the computer. troller. When the system enters a flash ROM programming 

A peripheral device, such as a CDROM, is used for descrip- mode, task files used in the IDE interface are redefined 

tions as shown in FIG. 1. In FIG. 1, the system includes a Subsequently, all activities to read/write task files by the host 

microprocessor 100, which serving as a controller is used to 60 computer will be interpreted with new definitions by the 

command all components, such as a servo 102 and a decoder flash controller so that a firmware code from the host 

104 of a CDROM. The servo 102 is coupled to a CD 106 to computer is written into the flash ROM through the flash 

read data stored in the CD 106. The firmware code controller. After the flash ROM is completely programmed, 

including, for example, a control program and other infer- the task files return to their original definition. The micro- 

mation is stored in a flash ROM 108. The firmware code 65 processor will be disabled to access to the flash ROM during 

provides instructions for the microprocessor 100 to execute. the flash ROM programming mode. If several flash ROM 

The CDROM communicates with a host computer 110 programming cycles are needed in one host request, the 
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firmware can be temporarily stored into a buffer, such as a processor 200 should stop access to the flash ROM 202 to 
RAM and then sequentially written into the flash ROM avoid bus contention until the flash ROM 202 is completely 
through the flash controller. Since the software method may programmed. Normally, after the flash ROM 202 is corn- 
occupy too much time of the IDE interface, resulting in a pletely programmed, the flash controller 204 disables the 
delay for the other subsequent activities, the hardware 5 R^h ROM programming function and all IDE activities are 
method may be a better way to update the firmware code, treated back to their original definition to perform a normal 
particularly to a large firmware code. mode operation for the periphery device coupled to the 

microprocessor 200 like the CDROM in FIG. 1. 

BRIEF DESCRIPTION OF DRAWINGS In detail, whenever the host computer (Host) 208 makes 

The invention can be more fully understood by reading 10 JSffiSJ^ 

the following detailed description of the preferred lT^l7. h * c l ™<*™%* * 

embodiment, with reference made to the accompanying 2* ^ Tp t ^ ^ ™ s f ubse ^ ent 

drawings as follows: P ^ g activities to flash ROM cycles so as to perform program- 

- . , - i j ■ . inmg- Upon the completion of programming, the Host 208 

FIG. 1 is system block diagram, schematically illustrating writes another vendor-specific IDE command to inform the 

a conventional computer system with a periphery CDROM, 15 system 0 r just re-boot the system. Sequentially, the system 

which is controlled by a firmware code stored in a flash returns to the normal mode. 

' _ . L1 , J . , All flash ROM cycles issued by the flash controller 204 

FIG. 2 is system block diagram, schematically illustrating C an be divided into two types. One is called a software cycle 

a computer system used to program a flash ROM, which and the other one is called a hardware cycle. Both of them 

usually is used to store a firmware code to control a 20 providc read and wntc functions as well. Iff the software 

periphery device, according to a preferred embodiment of cycle, the Host 208 directly control the status of flash pins 

the invention; of me flash R0M 202 so as to generate proper waveforms 

FIG 3 is a time sequence, schematically illustrating wave- used to read or write the flash ROM 202. The ATA task files 

forms of several control bit signals in a task file to produce have been re-defined to give the capability for the software 

a software read cycle, according to the preferred embodi- 25 cycle. 

ment of the invention; and For example, four registers in ATA task files are re-defined 

FIG. 4 is a time sequence, schematically illustrating as shown in table 1. 
waveforms of several control bit signals in a task file to 

produce a software write cycle, according to the preferred TABLE 1 
embodiment of the invention. 30 



DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENT 

A firmware code, which is usually stored in a flash ROM 
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computer, is often needed to be updated during development 

A conventional method to update the firmware is inconve- AllpinsjSf the flash ROM 202, such as a 64Kx8 flash 

ment and is also system-type dependent. ROtt^be mapped into the bits of these four registers, in 

Since an integrated device electronics (IDE) interface is which if other flash ROM with different size is used, extra 

generally used in periphery devices to communicate with a 40 pins are aeC essary to be mapped as wellrFor example, if a 

host computer. The invention provides a system using a flash 128kx8 flash ROM is used, an extra piri^JiWs needed to add 

controller to re-interpret all IDE bus activities and issues a ml0 these four registers to provide the control-lability on it. 

read/write flash ROM cycle to directly program the flash fa this manner, the Host 208 can write them to set or clear 

ROM. mese pins an d construct read or write cycle waveform 

FIG. 2 is system block diagram, schematically illustrating 45 arbitrarily. The status of the pins can be also obtained by the 

a computer system used to program a flash ROM, which Host 208 by reading these registers. In Bit3 of CTL register, 

usually is used to store a firmware code to control a DRV is defined to allow the Host 208 to decide whether to 

periphery device, according to a preferred embodiment of drive a data bus or not. It is to avoid a bus contention since 

the invention. A device system includes a microprocessor a flash ROM data bus usually is bi-directional and both of 

200, a flash ROM 202, and a flash controller 204. The 50 the flash controller and t he flash ROM can d rive the data bus, 

system can communicate with a host computer 208jhmugh The following sequence shows how the Host 208 to 

an IDE interface. The system can further include a^KAM 20$\ program those four registers to generate a software read 

to serve as a buffer. The flash controller 204 is couplfcHo-trjC cycle with the waveform shown in FIG. 3. 

PnL C ?m PUt H ?u* l ' hrOUgh ^L interf 1 Ce> ThC , fl f sh // assume all Bash related pins have been the inactive 

ROM 202 and the microprocessor 200 are also coupled to t t 

the flash controller 204. The RAM 206 can be also coupled 55 „ I ' „ . . . „. . _ 

to the flash controller 204. As is to be described later in " Le '' ^"kgh, oe#high, wr#-higb, and 

detail, the system can be operated in a software cycle and a // data pins are left floating, 

hardware cycle. The RAM 206 is needed to serve a buffer as write_ABUSLOW(????_????); // program desired read 

the system is operated in a hardware cycle, in which several address 

2*^ «Sw S? 05 arC DCeded " ° De rCqUCSt t0 UpdatC ^ 60 write_ABUSHIGH(????_????); // program desired read 

flash ROM 202. address 

When the system enters a flash ROM programming mode, wnte.CTL (0000_0110); //clear cs# 

task files used m the IDE interface are redefined so that a ^ /nn nn nni n\ „ i u 

firmware code from the host computer 208 is written into the wnte_CTL (0000_0010); //clear oe# 

flash ROM 202 through the flash controller 204. The task 65 // wait for Flash ROM access time . . . 

files, for example, are defined in ATA specification and are ReadBackData«read_J)BUS; 

used as a register-level communication interface. The micro- write_CTL (0000__0110); //set oe# 
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write_CTL (0000__0111); //set cs# 

Similarly, the following sequence shows how the Host 
208 to program those four registers to generate a software 
write cycle with the waveform shown in FIG. 4. 

// assume all Flash pins have been the inactive state, 

// i.e., cs#=high, oe#»high, wr#=high, and 

// data pins are left floating, 

write_ABUSLOW(????_????) ; //program desired write 
address 

write_ABUSHIGH(????_????); //program desired write 
address 

write_CTL (000(L_0110); //clear cs# 
write_CTL (OOOOJUOO); //clear wr# 
write_DBUS (????__????); //program desired write data 
write_CTL (0000_1100); //set DRV and begin to drive 
data bus 

write_CTL (00O0__1110); // set wr# 

write_CTL (0000_0H0); //clear DRV and float data bus 

write_CTL (O000_0111); //set cs# 

Most Flash ROM's provide a command set to perform 
erase, chip identification, protect write, and so on. These 
commands are generally made up by reading/writing spe- 
cific data to a specific address. Since the software cycles 
have more flexibility, they are useful for the Host 208 to 
issue the vendor-specific flash commands. The vendor- 
specific flash commands also includes a purpose to confirm 
the desired action so as to ensure the flash ROM 202 is 
exactly at the status for programming. 

In the above descriptions, the flash ROM 202 is pro- 
grammed through a software cycle. The RAM 206 in FIG. 
2 is not necessary to be used. In the invention, the software 
cycle is only one of choices. Even though the method to 
program the flash ROM 202 through the software method 
has advantages of the invention, a hardware method is also 
introduced. When the software method of the intervention is 
used in the programming process to program the flash ROM 
202, the IDE interface is occupied. If the firmware code has 
a large size to be updated, it may take long, resulting in a 
delay for the subsequent other IDE activities and a reduction 
of the system performance. A hardware method is intro- 
duced to further solve this problem. In the perspective of 
efficiency, hardware cycles may provide another better 
method when burst transfer is required. 

In FIG. 2, for the hardware cycles, the firmware code are 
transferred to the flash ROM 202 by two steps. For example, 
in hardware write cycles, the first step is that the Host 208 
first writes data, such as the firmware code, into the RAM 
206 through the flash controller 204. The RAM 206 serves 
as a buffer. The flash controller 204 then transfers the 
buffered data in the RAM 206 into the flash ROM 202 in the 
second step. In Hardware read cycles, the first step is that the 
flash controller 204 reads data from the flash ROM 202 and 
stores them in the RAM 206, then the Host 208 can read data 
from the RAM 206 in the second step. 

Two vendor-specific IDE commands are respectively 
defined for the hardware read cycle and the hardware write 
cycle. Moreover, three registers in the ATA task files are used 
as listed in table 2: 
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When the Host 208 wants to initiate the hardware write 
cycle, it firstly write the command/status register to initiate 
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an IDE hardware write command, which is one of the 
vendor-specific IDE commands. After receiving the 
command, the system sets the BSY bit and clears the DRQ 
bit, as shown in table 2, to indicate that it is at the busy state 
5 and no data transfer is requested. The system the is preparing 
for transferring data from the Host 208. At the meantime, the 
. Host can process other tasks. As soon as it is ready, the BSY 
bit is cleared and the DRQ bit is set, then an IDE interrupt 
is issued to inform the Host 208. When the Host 208 polls 

10 the STATUS register, if the result is that the BSY bit is 
cleared and the DRQ bit is set, the Host 208 starts to write 
data into the DATA register and the data are stored into the 
RAM 206 through the flash controller 204. When the system 

15 receives data of bytes specified in LENGTH register, it 
clears the DRQ bit and sets the BSY bit again to inform the 
Host 208 to stop sending data. Then, the flash controller 204 
automatically starts to issue subsequent write cycles and 
writes the data stored in the RAM 206 into the flash ROM 

20 202. As the data transferring accomplishes, the device 
system clears the BSY bit and finishes the hardware write 
cycle. It must be noted that the Host 208 needs to give the 
initial value to the ADDRL (ABUSLOW) and ADDRH 
(ABUSHIGH) registers in the task file serving as a starting 

25 address before initiating the IDE hardware write command. 
The flash controller 204 is responsible to increase it after 
every successful data transferring. 

Similarly, when the Host 208 wants to initiate the hard- 
ware read cycle, it firstly write the command/status register 
to initiate an IDE hardware read command which is one of 
the vendor-specific IDE commands. After receiving the 
command, the device system sets the BSY bit and clears the 
DRQ bit, then starts to issue read cycles to the flash ROM 

35 202 and stores data from the flash ROM 202 into the RAM 
206. The LENGTH register decides how many bytes of data 
are to be transferred. Upon the completion, the device 
system clears the BSY bit and sets the DRQ bit to request the 
Host 208 to read data on the RAM 206 through the DATA 

40 register. After the Host 208 reads all data, the device system 
clears the BSY bit and the DRQ bit. The hardware read cycle 
then is accomplished. It is noted that the Host 208 must give 
initial values to the ADDRL and ADDRH registers to serves 
as a starting address before issuing the IDE hardware read 

45 command. The flash controller 204 is responsible to increase 
it after every successful data transferring. 

In summary, four vendor-specific IDE commands are 
added in the architecture of the invention and five registers 

50 in the ATA task files are re-defined when system enters Flash 
. ROM programming mode. The new-added commands are 
listed as follows: 

PROGRAMMING_FLASH__ON, used to switch the 
system to the flash ROM programming mode; 

55 PROGRAMMING JLASH^OFF, used to switch the 
system to the flash ROM programming mode; 

HARDWARE_JYRITE, used to trigger the write cycle; 
and 

60 HARDWARE_READ, used to trigger the read cycle, 

where the last two are just for the hardware cycle. All ATA 
task files with their definition in flash ROM programming 
65 mode is described in the following table, in which the five 
registers LENGTH, CTL, DBUS, ABUSLOW, and 
ABUSHIGH are redefined. 



